In the computer hardware industry, there is a trend to develop devices with unique functionality. For example, hardware vendors seek to incorporate unique (e.g., proprietary) features to differentiate their device(s) from that of competitors. For example, even though register-based devices (e.g., debugger port, EMS port, system timer, interrupt controller, bus controller, . . . ) employ hardware registers for communication and control, such devices can utilize the hardware registers in disparate manners depending on the vendor's design specification. Resources of register based devices include I/O, memory mapped or Configuration Registers. Register(s) can be physically located within the hardware or in another location, the size of a register(s) can vary (e.g., 16 bit, 32 bit, . . . ), the function of a respective bit can vary, hardware functionality can differ depending on whether a bit is written to or read from, or how it is written to or read from, etc.
Traditionally, utilization of these functionalities (e.g., unique to specific device, common within a class of devices, . . . ) associated with register based hardware required developing a software driver that was hardware specific such that the driver correlated with semantics of the particular device. Numerous limitations result from the need for hardware specific device drivers. High costs are often associated with developing hardware specific device drivers, extensive software development time can be required to develop software capable of employing unique hardware functionalities, hardware development and utilization typically is slowed by unavailability of software capable of taking advantage of unique features of the hardware initially when new hardware functionalities are created, and software development can be slowed because the software must conform with requirements of the hardware.
Another shortcoming of conventional register based hardware is that hardware can be inaccessible prior to operating system kernel availability because a hardware specific device driver is required to interact with the device. Some operating system environments require access to the device prior to operating system boot up. Such limitation can render the hardware unusable for applications, such as, for example, a watchdog timer implemented to detect and respond to system failures prior to boot up and during initialization.
There exists a need in the art for systems and methods that can facilitate operation of hardware devices during the entire lifetime of the operating system, including boot and shutdown time. Additionally, there exists a need for a simple, common platform to describe hardware functionality to reduce costs and time associated with developing hardware specific device drivers. Furthermore, systems and methods are lacking which are extensible to enable utilization of additional features in future hardware. Thus, there exists a need in the art for a system and/or method for utilizing a common language for performing high level actions.